Talk:Location
Persistent locations Is it worth noting that locations - as in the case of a location saved as a local variable or campaign variable - become unpredictable or invalid when "Build Module" is performed? (Not sure if it's necessary to add a new area before doing the Build; seems to be something about areas being assigned unique IDs when a Build is performed, and those IDs being part of a location object.) I ran into this issue in my ever-growing multiplayer module when creating reprogrammable teleport items that store their destinations locally on the item, but I don't know if that's beyond the scope of this wiki, or if that information belongs in the Variables article, or etc. BCH 21:35, June 5, 2012 (UTC) :The NBDE has a way of storing this information. Basically it stores as a 52 character string the following information: five characters are reserved for each of the x, y, and z floats (decimal counts as a character), five characters are reserved for the angle (facing parameter), 32 characters are reserved for the tag of the area (this is maximum size for the area's tag). WhiZard 18:23, June 6, 2012 (UTC) * Locations as campaign variables? Oh, BioWare did provide that function. I wonder why? As you surmised, one of the parts of a location is (basically) an index into the list of objects. (The other parts are a position vector and a float storing the facing.) This index is meaningless outside the current module, and unreliable if the current module is restarted. Basically, a location stored in a campaign variable is largely worthless. : For persistent locations, it is a much better idea to store the location's area's tag along with the location's position vector and facing (as apparently NBDE does). This would allow you to reconstruct that location, assuming each area has a unique tag, and does not rely upon the object index. (The need for unique tags is one reason BioWare could not implement this; strictly speaking, all areas–or even all objects–in a module could have the same tag.) : As for where this could be located in NWNWiki, maybe in SetCampaignLocation()? --The Krit 20:18, June 6, 2012 (UTC) ::* Actually NBDE goes one step further away from campaign database storage and only stores one variable in its database. This would be an object (a creature) whose inventory items are akin to databases as they store a wide variety of information locally. Thus when a server begins it will unload the databases by creating the object. To store information it will delete the actual campaign database and then store within that campaign database the object on whose items all information is stored, and finally delete the object from the game. WhiZard 23:04, June 6, 2012 (UTC) :::* I definitely have to bow to the greater understanding that you two have of this topic; I don't even feel qualified to write up such an issue for NWNWika - other than just quoting what you two wrote here. ;-) However, regarding where to put such information, I think it would be most useful to create an article titled something like LocationVariableIssue so that it can be linked from a short note in each of multiple existing articles: Variable, Location, SetCampaignLocation(), GetCampaignLocation(), SetLocalLocation(), GetLocalLocation(), etc., so it is easily findable, but not duplicated. That would definitely help duffers like me find that information most reliably when we come looking for it. BCH 03:10, June 8, 2012 (UTC) * I put some information here, and I suppose it should also get mentioned under Get/SetCampaignLocation() once I get around to creating those articles. (I was going to do them today, but I think I'm out of time for this.) --The Krit 20:11, June 28, 2012 (UTC)